Joseph A. Raelin. Public Reflection as the Basis of Learning. Management Learning, Vol 32(1): 11-30, 2001. j.raelin_public-reflections-2001.pdf.pdf

It is obvious that people learn efficiently from (project) experience and mistakes. Anyway there are some comments that suggest we should concentrate into the strengths of the ”team members”

1. ”When we have tried to improve the bad habbits, they disappear in the beginning of the next project, but come back later on”, group manager, 2004.
2. ”It is very, very difficult to change someone…”, Roger E. Allen (1994).

After recounting the misadventure of Pooh and his chums trying to un-Bounce Tigger, the Stranger observes, “It is very, very difficult to change someone … In addition, even if we could, we would probably prefer the person the way he was, as your story shows.”

“But if you can't change people,” asked Owl, “how does the manager carry out her responsibility of developing people?”

“That's the funny thing about this function of a manager. You see, the manager really can't develop people. It just can't be done. All she can do is to provide an environment that encourages them to develop themselves.”

Some more comments available from: http://www.businessforum.com/toc.html,checked 2005-03-03

Lightweight PMA, Teaching material for the university course in Norway (2004): pma_practical_guide.pdf

Goodbye Postmortems - Hello Critical Stage Analysis by Wolfgang Hamann (Radical) at: http://www.gdconf.com/archives/2003/

Participants: Esther Derby, Linda Rising, Debra Schratz

- Note: written in the agile style

1. What kind of retrospectives are wanted (business vs. practitioners)?
2. What is the best way to 'create' change (people's strengths/'weaknesses')?
3. Are practitioners willing to share their knowledge, if a survey is done (one example of the survey topics would be how retros are done in practise - frequency, etc. to provide quantitative data)?

Some examples from the retros:

• 4 day retro after a 4 year project (it was noticed that nothing worked when the project was supposed to be finished, 'integration' test was not done properly)
• 2 day retro after a 3 year project (everything was wrong with the hardware and software, and a new project had to be started with 'empty' hands)

Majority of retros are done as follows depending on the person/project, and facilitatators role: external vs. internal

• #1: 2-3 days, when project's lenght has been over a year or more
• #2: only 1 day allowed weather the project has lasted few months or several years
• #3: typically 4 hours (aim is to have 6 hours in the future) in a milestone retro
• #4: only 1 hour also after 6 months when the facilitator is internal, knows the domain, people etc.

#5: Example of coming up from 2 hour retros into 2 days retros: when the company's internal facilitator could demonstrate that longer retrospective brought better understanding from the project (proof to the management) a BIG change happened. Once the company has seen that longer retro is more benefitial they don't want to go back to short retros.

Why do we need retros (our basic needs): everybody wants to do a good job.

How could practitioners possibly improve their practices (or get new ideas)? By following up [as an observer] the other facilitator doing her retro.

How do we do retros? One example is timeline and appreciations. The following things are needed ('items' 1-4 illustrate facilitators needs and the item 4 illustrates the 'one and only' business interest):

1. getting objective data
2. emotional data by persons (feelings on top of timeline)
3. insights
4. what are you going to do about it (action items)

Note: you may want to check the following publication by the VTT Reseach Center in Finland (comment by Mauri): Self-Adaptability of Agile Software Processes: A Case Study on Post-Iteration Workshops (2004), XP 2004, Germany http://agile.vtt.fi/docs/publications/2004/2004_self_adaptability_of_agile_software_processes.pdf

It seemed to be the common feeling that “consentrating on the [team members'] strengts could be innovative (but it is not easy to find out your personal strenghts) with 'agile' concepts. One proposed solution was: make sure [while starting a project] that you have people with their strengths in all [essential and] different areas.

The following literature was proposed to be read (in no order of importance):

• Maverick : The Success Story Behind the World's Most Unusual Workplace by Ricardo Semler (1995)
• First, Break All the Rules: What the World's Greatest Managers Do Differently by Marcus Buckingham, Curt Coffman (1999)
• Diffusion of Innovations, 5th Edition by Everett M. Rogers, Everett Rogers (2003)
• Some book of Virginia Satir
• FearlessChange: Patterns for Introducing New Ideas by Mary Lynn Manns, Linda Rising (2004)

YES :)

There is a will to provide data via survey.

Time to plan, check, … and do it: spring-summer 2005 (possibly together with Heather Nelson)

Small request: When survey data is analyzed, please let the people participating into the survey also to know the results.

What else could be done: mining of current retrospective data (to provide insights)

Thanks for the participants and people at the gathering for their comments.